The rise in popularity of portable electronic devices has led to a corresponding increase in demand for low-power FPGAs. For instance, it is increasingly desirable for hand-held devices to utilize low-power FPGA controllers that do not detract from long battery life. Ongoing efforts therefore exist to develop and refine FPGAs that consume less power, and are thus more compatible with portable and hand-held applications. Such ongoing efforts may include those that heretofore were not publically known and thus, it is to be understood that this Background section may include concepts and teachings that are not part of the prior art.
Concurrently, performance demands on such portable electronic devices continue to increase. Therefore, FPGAs used in these devices should desirably be structured to not only consume less power, but also to exhibit higher performance (e.g., high switching speeds). Accordingly, the ongoing efforts that currently exist include efforts to develop low-power FPGAs that also exhibit higher performance.
One heretofore and generally overlooked area in the ongoing efforts is FPGA carry chains, e.g., the logic used for generating and moving carry bits between successive stages during addition/subtraction operations. In particular, conventional FPGA carry chains typically consume excessive power and/or perform relatively slowly. As one example, FIG. 1 illustrates a plurality of FPGA Configurable Logic Blocks (CLBs) configured and interconnected for implementing a conventional ripple carry adder. Each configurable logic block 10 (e.g., CLB 100) receives two addend input bits (e.g., I0, I1), along with a corresponding carry bit, e.g., C0 from a previous stage and the respective CLB (10k) is configured to produce a respective sum bit Sk (k=0, 1, 2, etc.). Thus, the bottom logic block 100 of FIG. 1 adds corresponding input bits I0(0), I1(0), along with corresponding carry bit C0, to produce the respective sum bit S0 and the output carry bit C1, where the output carry bit is a 0 or 1 depending on the result of the addition of I0(0), I1(0) and C0. The output carry bit C1 is then transmitted to the next configurable logic block 10 (e.g., CLB 101), where it is used in calculating the next sum bit S1, and so on. It can be observed that, due to the ripple up way in which signals are generated and forwarded to the next successive stage, the dependency of the more significant stages (e.g., CLB 103) on receiving valid (e.g., settled) results from carry operations of the less significant stages (e.g., CLB 100) in this ripple carry adder contributes to latency and delay given that each previous carry bit must settle into a correct state before the next addition operation can commence in the next more significant stage. That is, each logic block 10(k) must wait for the carry output bit from the previous logic block 10(k−1) to be fully determined (e.g., well settled into a deterministic state). This delay is detrimental to the performance of FPGAs that employ such ripple carry adders. Furthermore, such, inside-the-CLB and ripple-based carry logic generally exhibits detrimental leakage current, leading to power drain even when a carry operation is not being actively performed inside the CLB.
As another example of conventional design, FIG. 2 illustrates an FPGA where its configurable logic blocks (e.g., CLBs 200-203, 30) are programmed to implement a conventional carry look-ahead adder. Each logic block 20 adds together its correspondingly received inputs I0(k), I1(k) together, along with its received carry bit C(k), and outputs the respective sum bit S(k). The logic blocks 20 also output respective propagate and generate signals PG(k) to a carry look-ahead block 30, where the state of PG(k) is based on whether a carry is to be further propagated from a less significant stage or a carry is to be generated at that stage (CLB 20k). The carry look-ahead block 30 determines from the PG signals whether a carry is to be propagated to the next block, and sends carry signal C(k) accordingly to stages 201-204, (last stage not shown). However, while the carry look-ahead adder helps reduce the problem of latency, the carry look-ahead block 30 still requires some time to process the PG signals and to generate the correct set of carry signals C for generating a correct final sum signal, S0:Sn. Additionally, the carry look-ahead adder, like the ripple carry logic, typically exhibits a leakage current even when unused for performing addition operations.